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Dear Sir: 

Appellants submit this appeal brief under 37 C.F.R. § 41.37 appealing the final 
rejection of Claims 1-18 in the Office Action mailed October 18, 2006. 
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( 1) Real Party in Interest 

The real party in interest is Sonic Solutions. 
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(2) Related Appeals and Interferences 



No related appeals or interferences are known to Appellants. 
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(3) Status of Claims 

Claims 1-18 were submitted for examination in the application filed on January 20, 

2000. 

Claims 1, 6-7, 12-13 and 18 were amended during prosecution. 

Claims 1-18 were finally rejected in the October 18, 2006 final office action. 

Claims 1-18 are appealed. 
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(4) Status of Amendments 

No amendments have been filed subsequent to the final rejection mailed May 5, 2006. 
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(5) Summary of Claimed Subject Matter 



Independent Claims Subject Matter Map 



Receiving requests from each of the client apparatuses to 
simultaneously playback the event (enabled with, for example, a 
code segment or logic) 


Claims 1, 7, 13 


Identifying a type of the playback device of each of the client 
apparatuses (enabled with, for example, a code segment or logic) 


Claims 1, 7, 13 


Looking up a command associated with the identified type of the 
playback device (enabled with, for example, a code segment or 
logic) 


Claims 1, 7, 13 


Determining whether each request is received during a predefined 
threshold period prior to a start time of initially beginning the 
simultaneous playback of the event (enabled with, for example, a 
code segment or logic) 


Claims 1 7 13 


Sending the command to the corresponding client apparatus for 
initially beginning the playback of the event at the start time 
simultaneously with the playback of the event on each of the 
remaining client apparatuses for those requests received during the 
predefined threshold period, and sending the command to the 
corresponding client apparatus for beginning the simultaneous 
playback of the event simultaneously at a predetermined point 
during the playback for those requests not received during the 
threshold period (enabled with, for example, a code segment or 
logic) 


Claims 1, 7, 13 



A concise explanation of this subject matter appears as follows (with corresponding 



references to the specification by page and line number (or paragraph numbering where 
appropriate) and to the drawing(s) (if any) by figure number and reference characters. 1 

The claimed embodiments are directed to methods, computer programs and systems 
to provide simultaneous playback of events. 2 Further, these embodiments can further identify 
playback devices of a plurality of client apparatuses that are networked and effect simultaneous 



1 There are no specifc means plus function (or step plus function) recitations in any of the claims involved in this 
appeal, and thus, there is no identification of any corresponding structure, material, or acts in the specification in this 
regard. It will be understood that this summarization of the claimed subject matter is, in fact, a "summary" and that 
the Applicants do not represent or intend that this brief presentation, or the accompanying references to the drawings 
and the specification, comprises an exhaustive presentation in this regard. As always, the claims are to be viewed 
and interpreted in view of the context of the entire specification and the Abstract. 

2 See at least App. pg. 7, lines 3-10; pg. 10, lines 3-15. 
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playback of an event at the client apparatuses. FIGS. 7 and 10 from the application appears 
below for the convenience of the reader showing example processes of providing simultaneous 
playback according to some embodiments: 



RECEIVING A REQUEST UTILIZING A NETWORK FOR VIEWING AN EVENT 



QUEUING THE REQUEST IN ME 



CREATING AN OBJECT IN RESPONSE TO THE REQUEST, THE OBJECT ADAPTED 
PLAYBACK THE EVENT ON A CLIENT APPARATUS SIMULTANEOUS WITH THE 
OF THE EVENT ON THE REMAINING CLIENT APPARATUSES UPON THE RECE 
ACTIVATION SIGNAL 



Figure 7 
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IDENTIFYING A TYPE OF THE PLAYBACK DEVICE OF EACH OF THE CLIENT APPARATUSES 



SENDING THE COMMAND TO THE CORRESPONDING CLIENT f^rUS FOR BEGGING 
THE PLAYBACK OF THE EVENT SIMULTANEOUSLY WITH THE PIAY^CK OF THE EVENT 
ON EACH OF THE REMAINING CLIENT APPARATUSES 



Figure 10 



More specifically, some embodiments provide methods that identify playback devices 
of client apparatuses that are networked to simultaneously playback an event 3 of client 
apparatuses requesting simultaneous playback 4 . A type of playback device is identified for each 
of the client apparatuses for which requests are received and commands associated with the 
identified type of the playback device are identified. 5 The received requests are evaluated to 
determine whether the request is received during a predefined threshold period prior to a start 
time of initially beginning the simultaneous playback of the event. 6 Further, the identified 
command is sent to the corresponding client apparatus for initially beginning the playback of the 
event at the start time simultaneously with the playback of the event on each of the remaining 
client apparatuses for those requests received during the predefined threshold period. 7 For 



3 See at least App. FIGS. 3, 7 and 10; pg. 22, lines 20-32; pg. 29, lines 14-26. 

4 See at least App. FIGS. 2-8 and 9; pg. 21, lines 24-33; pg. 23, lines 10-14; pg. 24, lines 10-24; pg. 28, lines 9-33; 

pg. 29, lines 14-26; pg. 32, lines 4-19; andpg. 36, lines 12-17. 

5 See for example, App. FIGS. 3, 7 and 10; pg. 22, lines 9-12; pg. 22, lines 20-27; pg. 28, lines 9-32; pg. 29, lines 

14-32; p. 31, lines 12-17; pg. 32, line 27 - pg. 33, line 6; andpg. 40, lines 5-16. 

6 See at least App. FIGS. 5, 7-8 and 17; pg. 24, lines 10-26; pg. 29, line 14 - pg. 30, line 9; pg. 30, lines 13-32; pg. 

31, line 12-17 and lines 22-32; andpg. 36, lines 6-17. 

7 See at least App. FIGS. 2, 4-10, 17, 18; pg. 21, line 29 - pg. 22, line 16; pg. 23, lines 10-14; pg. 24, lines 10-14; 
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requests not received during the threshold period the identified command is sent to the 
corresponding client apparatus for beginning the simultaneous playback of the event 
simultaneously at a predetermined point during the playback. 8 

Below is a table providing a summarization of the description above and examples of 
supporting description within the specification. This representative table is, in fact, a "summary" 
and that the Appellants do not represent or intend that this brief presentation, or the 
accompanying references to the drawings and the specification, comprises an exhaustive 
presentation in this regard. As always, the claims are to be viewed and interpreted in view of the 
context of the entire specification and the Abstract. 



Requests are received from the client apparatuses 


See at least App. FIGS. 2-8 and 9; pg. 21, 
lines 24-33; pg. 23, lines 10-14; pg. 24, 
lines 10-24; pg. 28, lines 9-33; pg. 29, 
lines 14-26; pg. 32, lines 4-19; and pg. 
36, lines 12-17 


A type of playback device is identified for each of 
the client apparatuses and commands associated with 
the identified type of the playback device are 
identified 


See for example, App. FIGS. 3, 7 and 10; 
pg. 22, lines 9-12; pg. 22, lines 20-27; pg. 
28, lines 9-32; pg. 29, lines 14-32; p. 31, 
lines 12-17; pg. 32, line 27 - pg. 33, line 
6; and pg. 40, lines 5-16 


Requests are evaluated to determine whether the 
request is received during a predefined threshold 
period prior to a start time of initially beginning the 
simultaneous playback of the event 


See at least App. FIGS. 5, 7-8 and 17; pg. 
24, lines 10-26; pg. 29, line 14 - pg. 30, 
line 9; pg. 30, lines 13-32; pg. 31, line 
12-17 and lines 22-32; and pg. 36, lines 
6-17 


Command is sent to the corresponding client 
apparatus for initially beginning the playback of the 
event at the start time simultaneously with the 
playback of the event on each of the remaining client 
apparatuses for those requests received during the 
predefined threshold period 


See at least App. FIGS. 2, 4-10, 17, 18; 
pg. 21, line 29 - pg. 22, line 16; pg. 23, 
lines 10-14; pg. 24, lines 10-14; pg. 28, 
line 9 - pg. 29, line 10; pg. 29, line 20 - 
pg. 30, line 9; pg. 32, lines 4-23; pg. 32, 
line 27 - pg. 33, line 10; pg. 36, lines 6- 
17; pg. 39,lines 13-23; pg. 44, line 19 - 
pg. 45, line 27 



pg. 28, line 9 - pg. 29, line 10; pg. 29, line 20 - pg. 30, line 9; pg. 32, lines 4-23; pg. 32, line 27 - pg. 33, line 10; 
pg. 36, lines 6-17; pg. 39,lines 13-23; pg. 44, line 19 - pg. 45, line 27. 
8 See at least FIGS. 2, 4-10, 17, 18; pg. 21, line 29 - pg. 22, line 16; pg. 23, lines 10-14; pg. 24, lines 10-14; pg. 28, 
line 9 - pg. 29, line 10; pg. 29, line 20 - pg. 30, line 9; pg. 30, line 13 - pg. 3 1, line 32; pg. 33, line 8-17; pg. 47, 
line 12 -pg. 49, line 20. 
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For requests not received during the threshold period 
the identified command is sent to the corresponding 
client apparatus for beginning the simultaneous 
playback of the event simultaneously at a 
predetermined point during the playback 



See at least FIGS. 2, 4-10, 17, 18; pg. 21, 
line 29 - pg. 22, line 16; pg. 23, lines 10- 
14; pg. 24, lines 10-14; pg. 28, line 9 - 
pg. 29, line 10; pg. 29, line 20 - pg. 30, 
line 9; pg. 30, line 13 - pg. 31, line 32; 
pg. 33, line 8-17; pg. 47, line 12 - pg. 49, 
line 20 



Other embodiments provide computer programs embodied on computer readable 
mediums for identifying playback devices of a plurality of client apparatuses which are 
networked to simultaneously playback an event. These computer programs can include a code 
segment to receive requests from each of the client apparatuses to simultaneous playback the 
event. 9 Further code segments identify a type of the playback device of each of the client 
apparatuses and that look up a command associated with the identified type of the playback 
device. 10 A code segment is also provided that determines whether each request is received 
during a predefined threshold period prior to a start time of initially beginning the simultaneous 
playback of the event. 11 An additional code segment is provide to send the command to the 
corresponding client apparatus for initially beginning the playback of the event at the start time 
simultaneously with the playback of the event on each of the remaining client apparatuses for 
those requests received during the predefined threshold period. 12 Still further, code segments are 
provide that send the command to the corresponding client apparatus for beginning the 
simultaneous playback of the event simultaneously at a predetermined point during the playback 
for those requests not received during the threshold period. 13 



9 See at least App. FIGS. 2-8 and 9; pg. 21, lines 24-33; pg. 23, lines 10-14; pg. 24, lines 10-24; pg. 28, lines 9-33; 

pg. 29, lines 14-26; pg. 32, lines 4-19; andpg. 36, lines 12-17. 

10 See for example, App. FIGS. 3, 7 and 10; pg. 22, lines 9-12; pg. 22, lines 20-27; pg. 28, lines 9-32; pg. 29, lines 
14-32; p. 31, lines 12-17; pg. 32, line 27 - pg. 33, line 6; andpg. 40, lines 5-16. 

See at least App. FIGS. 5, 7-8 and 17; pg. 24, lines 10-26; pg. 29, line 14 - pg. 30, line 9; pg. 30, lines 13-32; pg. 
31, line 12-17 and lines 22-32; andpg. 36, lines 6-17. 

1 1 See at least App. FIGS. 5, 7-8 and 17; pg. 24, lines 10-26; pg. 29, line 14 - pg. 30, line 9; pg. 30, lines 13-32; pg. 
31, line 12-17 and lines 22-32; andpg. 36, lines 6-17. 

12 See at least App. FIGS. 2, 4-10, 17, 18; pg. 21, line 29 - pg. 22, line 16; pg. 23, lines 10-14; pg. 24, lines 10-14; 
pg. 28, line 9 - pg. 29, line 10; pg. 29, line 20 - pg. 30, line 9; pg. 32, lines 4-23; pg. 32, line 27 - pg. 33, line 10; 
pg. 36, lines 6-17; pg. 39,lines 13-23; pg. 44, line 19 - pg. 45, line 27. 

13 See at least FIGS. 2, 4-10, 17, 18; pg. 21, line 29 - pg. 22, line 16; pg. 23, lines 10-14; pg. 24, lines 10-14; pg. 28, 
line 9 - pg. 29, line 10; pg. 29, line 20 - pg. 30, line 9; pg. 30, line 13 - pg. 3 1, line 32; pg. 33, line 8-17; pg. 47, 
line 12 -pg. 49, line 20. 
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Additionally or alternatively, some embodiments provide systems for identifying 
playback devices of a plurality of client apparatuses which are networked to simultaneously 
playback an event. These systems have logic to receive requests from client apparatuses to 
simultaneous playback the event. 14 Logic is also included that identify a type of the playback 
device of each of the client apparatuses, and logic is included to look up a command associated 
with the identified type of the playback device. 15 Further logic is provided to determine whether 
each request is received during a predefined threshold period prior to a start time of initially 
beginning the simultaneous playback of the event. 16 Logic to send the command to the 
corresponding client apparatus for initially beginning the playback of the event at the start time 
simultaneously with the playback of the event on each of the remaining client apparatuses for 
those requests received during the predefined threshold period is also included. 17 Additionally, 
logic is provided to send the command to the corresponding client apparatus for beginning the 
simultaneous playback of the event simultaneously at a predetermined point during the playback 
for those requests not received during the threshold period. 18 



14 See at least App. FIGS. 2-8 and 9; pg. 21, lines 24-33; pg. 23, lines 10-14; pg. 24, lines 10-24; pg. 28, lines 9-33; 
pg. 29, lines 14-26; pg. 32, lines 4-19; andpg. 36, lines 12-17. 

15 See for example, App. FIGS. 3, 7 and 10; pg. 22, lines 9-12; pg. 22, lines 20-27; pg. 28, lines 9-32; pg. 29, lines 
14-32; p. 31, lines 12-17; pg. 32, line 27 - pg. 33, line 6; andpg. 40, lines 5-16. 

16 See at least App. FIGS. 5, 7-8 and 17; pg. 24, lines 10-26; pg. 29, line 14 - pg. 30, line 9; pg. 30, lines 13-32; pg. 
31, line 12-17 and lines 22-32; andpg. 36, lines 6-17. 

17 See at least App. FIGS. 2, 4-10, 17, 18; pg. 21, line 29 - pg. 22, line 16; pg. 23, lines 10-14; pg. 24, lines 10-14; 
pg. 28, line 9 - pg. 29, line 10; pg. 29, line 20 - pg. 30, line 9; pg. 32, lines 4-23; pg. 32, line 27 - pg. 33, line 10; 
pg. 36, lines 6-17; pg. 39,lines 13-23; pg. 44, line 19 - pg. 45, line 27. 

18 See at least FIGS. 2, 4-10, 17, 18; pg. 21, line 29 - pg. 22, line 16; pg. 23, lines 10-14; pg. 24, lines 10-14; pg. 28, 
line 9 - pg. 29, line 10; pg. 29, line 20 - pg. 30, line 9; pg. 30, line 13 - pg. 3 1, line 32; pg. 33, line 8-17; pg. 47, 
line 12 -pg. 49, line 20. 
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(6) Grounds of Rejection to be Reviewed 

The following issues are presented for review: 

Issue 1: whether claims 1-18 are unpatentable under 35 U.S. C. § 103(a) over U.S. 
Patent No. U.S. Patent No. 6,161,132 to Roberts et al. (referred to below as the Roberts patent) 
in view of U.S. Patent No. 6,108,687 to Craig (referred to below as the Craig patent). 
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(7) Argument 

The following arguments are presented to contest the grounds for rejection presented 

above. 

Issue 1: Claims 1-18 are patentable over the Roberts patent in view of the Craig 

patent. 

Claim 1 

Claim 1 is rejected over the combination of the Roberts patent and Craig patent. This 
combination, however, fails to teach or suggest all of the limitations as recited in at least claim 1 . 

More specifically, Applicants respectfully submit that the combination of Roberts and Craig 
fails to teach at least "determining whether each request is received during a predefined 
threshold period prior to a start time of initially beginning the simultaneous playback of the 
event" as recited in claim 1. The office action of October 18, 2006 states on page 5 that 
"Roberts does not specifically teach that received requests during its threshold period occur prior 
to 'a start time of initially beginning' the playback" and instead relies on the Craig patent. In 
attempting to equate the combination of Roberts and Craig to the claimed limitations, the office 
action specifically defines a "simultaneous playback of an event" as "the chat room" of Roberts 
(office action, page 3 and page 4). Therefore, according to the office action's interpretation of 
Roberts, the event is started when the chat room is started. 

In relying on the Craig patent in attempting to show that the combination of Roberts 
and Craig describes receiving requests "prior to a start time of initially beginning the 
simultaneous playback of the event" the office action cites column 12, lines 7-21 of Craig where 
Craig describes what the office action refers to as an "'initiation' period" (office action, page 5). 

This "initiation" period described in Craig requires that "the user at the instructor workstation 
will preferably initiate the presentation some time in advance . This will allow students that 
attempt to connect to the presentation some window of time to establish their connections " 
(Craig, col. 12, lines 10-14, emphasis added). Therefore, according to Craig, participants must 
be able to establish their connections prior to a lecture. Roberts specifically requires that a chat 
room be started in response to a first user attempting to access the chat room and subsequent 
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users allowed to establish their connections and to join that already active chat room (see 
Roberts, at least col. 7, lines 26-30). The combination of the "initiation" period of Craig with 
Roberts would at best provide that participants of a chat room be able to establish their 
connections with the active chat room prior to a lecture beginning. The office action requires 
that the "chat room" is the simultaneous event (office action, see at least page 3 and also page 4). 
As such, the "event" (the chat room) is started once a single request is received and subsequent 
requests received are directed to the already started event (i.e., the existing chat room) where the 
users could wait an "initiation" period for an instructor (according to Craig) to begin lecturing. 
However, users are already actively participating in the "event" (the chat room) according to 
Roberts and Craig, and the combination does not receive requests prior to the event and there 
would be no reason to determine whether requests are received prior to the event (chat room) 
because the chat room according to Roberts is started immediately upon receipt of the first 
request. 

The chat room must be active (at least according to Craig) to allow users to establish 
their connections, and thus, would not determine whether requests are received prior to the 
threshold period. Therefore, the combination of Roberts and Craig fails to teach receiving 
requests prior to "a start time of initially beginning" the event, i.e., the chat room, and further 
fails to teach or suggest "determining whether each request is received during a predefined 
threshold period prior to a start time of initially beginning the simultaneous playback of the 
event" as recited in claim 1 . 

The office action continues to suggest that the users of the chat room in Roberts could 
be queued, relying on the "initiation" period of Craig. Combining Craig with Roberts, however, 
would not result in users being queued up and waiting to join an event (i.e., the chat room). 
Instead, at best, the combination would provide that a chat room must be activated and users 
allowed to establish their connections with and to join the active chat room prior a lecture 
beginning. Specifically, Roberts states that a first user activates a chat room and other users join 
that chat room, and further Craig specifically states that the presentation "must be initiated. . . 
some time in advance" (Craig, col. 12, lines 7-13), and thus, arguendo if one were to combine 
Craig with Roberts the combination would at best require that the chat room be activated some 
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time in advance of the lecture to allow users to join the chat room prior to the lecture. Thus, 
even if you combine the Craig and Roberts patents, the combination fails to teach or suggest 
queuing participants prior to the start of the chat room of Roberts, and instead teaches away from 
queuing prior to starting the chat room because the chat room must be active (at least according 
to Craig) to allow users to establish their connections. Therefore, the combination fails to teach 
or suggest a threshold period prior to the beginning of an event and also fails to teach 
"determining whether each request is received during a predefined threshold period prior to a 
start time of initially beginning the simultaneous playback of the event" as recited in claim 1 . 

Applicants further respectfully submit that neither the Roberts patent nor the Craig 
patent teach at least looking up a command associated with the identified type of the playback 
device and sending the command to the corresponding client apparatuses as recited in at least 
claim 1 . Instead, Roberts only describes sending or relaying generic commands to each chat 
client that are interpreted by a plug in on the clients to identify the command and implement an 
appropriate action. Nowhere does Roberts describe or teach looking up commands associated 
with the type of the playback device. 

The Office Action mailed October 18, 2006 suggests that the Roberts patent describes 
identifying a type of the playback device stating that "Roberts teaches a command plug-in for 
aiding in the playing of a musical recording, said plug-in gathers information regarding the 
capabilities of the client's CD drive, therefore determining the type of drive" citing the Abstract 
and column 4, lines 1-16 of Roberts (office action, pg. 3). Column 4, lines 1-16 of Roberts 
describes a command plug-in that provides basic functions including getting "information 
regarding the capabilities of the CD drive." The Roberts patent, however, fails to discuss or 
suggest looking up a command associated with the identified type of playback device and 
sending the command to the corresponding client apparatuses as recited in claim 1 . Getting 
information about the capabilities of a CD drive cannot be equated to looking up commands 
associated with identified types of playback devices and sending those commands to client 
apparatuses. Instead, Roberts only describes that a plug in that is stored and operated locally on 
the client device gets information regarding the capabilities of that CD drive. There is no 
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discussion or suggestion of looking up commands based on the type of playback device and 
sending that command to the playback device. 

Further, Roberts only describes sending generic messages that are acted upon by the 
plug in, and does not teach or suggest sending a command associated with an identified type of 
playback device. Specifically, Roberts describes sending messages where "[c]ontrol actions 
result in the chat plug-in sending messages to the chat server which describe the control action 
being taken ... the chat plug-ins running on the other users' machines, upon seeing a message of 
this kind, replicate the action (as far as possible) on the other users' machines by using the 
control plug-in" (Roberts, col. 8, lines 5-14). Therefore, the messages sent to the client 
apparatus and received by the chat client are generic messages that can be viewed and 
understood by all chat clients regardless of the type of device, and the command plug-in only 
locally causes the message to change the state of the playback device. The communication of 
generic messages is supported in that Roberts specifically states that it is "[a]n important 
advantage of the preferred embodiment . . . that it may be used with any chat server software 
which supports the minimal functionality ..." (Roberts, col. 8, lines 31-33, emphasis added). 
The Craig patent also fails to teach or suggest identifying a type of the playback device, looking 
up a command associated with the playback device and sending the command to the client 
apparatus as recited in claim 1 . Thus, claim 1 is not obvious over the applied combination. 

The office action further contends on page 4 that it "would have been obvious ... to 
apply the plug-in analyzing CD capabilities and controls, to Robert's chat room embodiment . . . 
providing Robert's the benefit of synchronization of audio CD devices with a wide array of 
different characteristics . . . ." As described above, however, the Roberts patent describes sending 
generic messages that are utilized by the plug-ins to implement the commands. Roberts already 
describes coordinating playback on multiple client devices without the need of identifying the 
type of playback device. One skilled in the art would not add the complexity to Roberts to 
identify the playback device or use this information in identifying commands as Roberts already 
describes coordinating the playback through generic messages. 

Furthermore, the combination of the Roberts and Craig patents fails to describe or 
suggest at least a predefined threshold period as recited in at least claim 1 . The Office Action 
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suggests that "a predefined threshold period of acquisition can be defined as the time during the 
active participation of a chat room," as described in the Roberts patent (Office Action, pg. 3). 
However, the predefined threshold period recited in claim 1 is prior to the start time of initially 
beginning the simultaneous playback of the event, and therefore, cannot be equated with a time 
period after the simultaneous playback of the event, which the Office Action equates with the 
chat room described in Roberts, on any of the client devices. As such, "time during the active 
participation of a chat room" cannot be equated with the predefined threshold period as 
suggested by the Office Action. 

Additionally, claim 1 does not simply recite a threshold period, but instead recites "a 
predefined threshold period prior to a start time of initially beginning the simultaneous 
playback." A "time during the active participation of said chat room" therefore, cannot be 
equated to the recited threshold period prior to a start time of an initial beginning of the playback 
because this period stated in the office action is after the start time of the playback. 

The Office Action, in the alternative, suggests that "the predefined threshold period 
can also be interpreted as the time between initial communication of said identifier, and the 
ultimate starting point of the simultaneous playback of an event (the chat room)" citing the 
Roberts patent (Office Action, pg. 3). The Roberts patent describes that once a unique identifier 
is received, and the server is searched for a chat room, the name of the chat room is sent to the 
browser and the browser starts a chat client on a client device (see Roberts, col. 7, lines 15-30). 
The Office Action attempts to equate this period between the initial communication of said 
identifier and the ultimate starting point of the chat session, with the predefined threshold period 
as recited in at least claim 1 . However, Roberts fails to teach or suggest making any type of 
determination relative to this suggested period whether requests are received. Instead, the only 
determination described in Roberts is whether a chat room is active when the request is received. 
There is no suggestion or motivation to make any determination relative to a time period from 
initially communicating an identifier and starting the chat room as Roberts specifically describes 
that "[i]f a chat room focused on the CD exists or can be created, the server responds with the 
name of that chat room , and the browser starts up a chat client on the user's computer as a client 
of that chat room ," and any subsequent requests are directed to be clients of that chat room 
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(Roberts, col. 7, lines 26-30, emphasis added). Therefore, Roberts does not determine whether 
requests are received relative to the suggested period, and there is no motivation to make such a 
determination as a chat room is activated immediately upon receipt of a first request. 

Further, there would be no benefit to comparing subsequent requests to this suggested 
period between initial communication of an identification from a first request and an activation 
of the chat room, because the chat room is active and all subsequent requests are associated with 
the already existing chat room. The period suggested in the office action is irrelevant to any 
subsequent requests because Roberts describes that the only determination relevant is whether 
the chat room is active or not. Therefore, the Roberts patent fails to teach or suggest determining 
whether requests are received prior to a predefined threshold period. 

Still further, the period between initial communication and starting of the chat room 
cannot be equated with the predefined threshold as recited in at least claim 1 . More specifically, 
the Office Action expressly states that "Roberts does not specifically teach that received requests 
during its threshold period occur prior to 'a start time of initially beginning' the playback", and 
instead relies on the Craig patent as teaching a predefined threshold period prior to a start time of 
initially beginning the playback as recited in claim 1 (Office Action, pg. 5). As such, at least 
neither of the time periods suggested by the office action relative to the Roberts patent, which 
the Office Action attempts to equate with the predefined threshold, can be equated to the 
predefined threshold period as claimed. 

Additionally as introduce above, the office action attempts to equate a response time 
between an "initial communication of a CDs identifier, to the ultimate starting point of a chat 
room" to the claimed "predefined threshold period" (office action, page 4). However, this 
response cannot be defined as a predefined threshold period because it is simply a response time. 
Further, this response time is not a "predefined" period, but instead varies with every user 
depending on the connection of the users computer, internet traffic, website traffic, chat room 
traffic and other effects, and thus, is not a "predefined" period but completely varying based on 
response times and network traffic. Still further, there would be no motivation to make any 
determination of whether this request is received during this period because the request has 
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already been received and the connection is being made. Therefore, this period cannot be 
equated to the "predefined threshold period" as recited in claim 1 . 

Still further in rejecting claim 1, the Office Action contends that an "initiation period" 
described in the Craig patent (i.e., the time between the lecturer's initiation of presentation with 
a slide showing title and presentation start time until the lecturer begins speaking and selecting 
slides) can be equated to the predefined threshold as recited in claim 1 (Office Action, pg. 5). 
Specifically, the Office Action states that the combination of Craig with Roberts would allow 
Roberts "the benefit of allowing all participating users to experience a multimedia chat session in 
its entirety, for better understanding of a presentation, especially in an education setting" (Office 
Action, pg. 5). The suggested "initiation" period of Craig relied on in the Office Action allows 
users to connect to the lecture presentation prior to an instructor speaking (see at least Craig, col. 
12, lines 7-16). However, such an initiation period as applied to Roberts would allow users to 
establish a connection with an already active "chat room," which is specifically intended to 
allow users to interact with each other. The "initiation" period of Craig requires that users 
connect with and join the chat room (i.e., the event according to the office action). Once users 
access a chat room they can communicate, including controlling the playback of a CD and/or 
otherwise interact as described in Roberts. It is the intended implementation of Roberts that the 
chat rooms of Roberts allow users to interact and participate in the experience (see at least 
Roberts, col. 1, lines 57-65). Even if one combined the "initiation" period of Craig with the chat 
room of Roberts, those users that access the chat room are actively participating in the chat room 
event and can control playback of the CD. These active users would be actively participating in 
the chat room and awaiting an "instructor" to begin lecturing. The chat room of Roberts does 
not restrict users from participating and instead teaches away from restricting users from 
participating as this would defeat the intended interactive and social aspect of the chat room. It 
would go directly against the intended implementation of Roberts to limit users from utilizing 
the chat room. Therefore, the combination fails to teach a threshold period as recited in claim 1 . 

Furthermore, combining Craig with Roberts would not result in users being queued 
up and waiting to join a chat room. Instead, at best, the combination would provide that a chat 



Page 20 of 35 

Application. No. 09/489,597 
Appeal Brief 

room must be activated and users joined to the chat room prior a lecture beginning. Specifically, 
Roberts states that a first user activates a chat room and other users join that chat room, and 
further Craig specifically states that the presentation "must be initiated. . . some time in advance" 
to allow users to connect (Craig, col. 12, lines 7-13), and thus, if one tried to combine Craig with 
Roberts the combination at best would require that the chat room be activated some time in 
advance of the lecture and allow users to join the chat room. Thus, even if you combine the 
Craig and Roberts patents, the combination fails to teach or suggest queuing participants prior to 
the start of the chat room of Roberts. Therefore, the combination fails to teach or suggest a 
threshold period prior to the beginning of an event as recited in claim 1 . 

Additionally, the office action in combining Roberts with Craig suggests that Roberts 
could queue participates of a chat room. Roberts, however, teaches away from users being 
queued as this goes directly against the teachings of the Roberts patent in that Roberts 
specifically describes that a chat room (i.e., the event according to the office action) is initially 
activated upon a first user's request to join a chat room. The Roberts patent does not teach or 
suggest queuing up requests and instead specifically teaches away from such queuing because 
upon receipt of a first request a chat room is immediately started and other requests are allowed 
to join. For example, Roberts states "[i]f a chat room focused on the CD exists or can be created, 
the server responds with the name of the chat room, and the browser starts up a chat client ... as 
a client of that chat room" (Roberts, col. 7, lines 26-30). Therefore, the Roberts patent describes 
starting a chat upon receipt of a first request and not queuing requests, and thus, there is no 
motivation to incorporate the period defined in Craig into the Roberts patent. 

In response to Applicants' prior arguments, the Office Action states that "Roberts can 
ultimately begin a chat room with a plurality of devices queued up and waiting" (Office Action, 
pg. 7), and further argues that applying Craig to Roberts would provide "Roberts the benefit of 
allowing all participating users to experience multimedia chat session in its entirety (i.e., begging 
a simultaneous chat session in its entirety, for better understanding of a presentation, especially 
in an educational setting" (Office Action, pg. 8). However, the Craig patent requires that the 
presentation be initiated in advance to allow users to establish there connection (see at least 
Craig, col. 12, lines 7-12). When combined with the chat room of Roberts, this "initiation" 
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period at best would require that the chat room be activated in advance to allow users to join the 
chat room event prior to the lecture. Further, Roberts explains that when a request is received 
"[i]f a chat room focused on the CD exists or can be created, the server responds with the name 
of the chat room, and the browser starts up a chat client ... as a client of that chat room" 
(Roberts, col. 7, lines 26-30). Therefore, when a request is received, the user is given the name 
and can start as a chat client of the chat room, therefore, a user request can never be queued up 
and instead is either replied to with the name of the requested chat room, or is denied if the chat 
room does not exist or cannot be created (see Roberts, col. 7, lines 15-30). As such, the Roberts 
patent teaches away from queuing users and instead teaches replying to each user request as soon 
as it is received regardless of when such user request is received. As such, the combination of 
the Craig "initiation" period and the Roberts patent results in users actively participating in a 
chat room event and waiting for a user of the chat room to begin a lecture. Therefore, the 
combination of the Roberts patent with the Craig patent fails to teach each limitation as recited in 
claim 1 . 

Additionally, neither the Roberts patent nor the Craig patent describe or suggest 
making a determination regarding whether requests are received during a threshold period as 
claimed. Instead, both Roberts and Craig describe connecting users to the chat room or 
presentation in response to receiving requests and neither describes or suggests determining 
whether requests are received relative to any predefined threshold period. More specifically, the 
Roberts patent describes receiving requests and activating a chat room upon receipt of a first 
request associated with a CD or, where a requested chat room exists, joining requests to the 
active chat room stating that "[t]he server then employs the unique identifier to determine 
whether it has a chat room focused on the CD ... If a chat room focused on the CD exists or can 
be created, the server responds with the name of that chat room, and the browser starts up a chat 
client on the user's computer as a client of that chat room" (col. 7, lines 21-30). Therefore, 
neither the Roberts patent or the Craig patent describes making a determination whether requests 
are received during a predefined threshold period as claimed. 

Further, the Roberts patent fails to suggest making a determination of when the 
requests are received relative to some time period or threshold. Specifically, when a user 
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connects by means of a browser to the "central Web page," the "central Web page" asks the user 
to insert the CD, after the user does so a unique identifier is computed and sent to the server, the 
server then uses the unique identifier to start up a chat client on the client device (Roberts, col. 7, 
lines 26-30). Where a chat session for the CD already exists or can be created, the Roberts 
patent fails to teach or suggest making any inquiry regarding what state the chat room is in (see 
at least Roberts, col. 7, lines 15-30). The server simply searches the database to determine 
whether a chat room exists or can be created and if a chat room exists or can be created the name 
of the chat room is sent to the browser which starts a chat client (see Roberts, col. 7, lines 26- 
30). Upon receiving the request, according to the Roberts patent, the user is simply provided 
with the name of the chat room and does not make any determination with regard to a specific 
time period or threshold and more specifically with respect to what state the chat room is in. The 
only determination Roberts makes upon receipt of a request to join a chat room is a 
determination of whether the chat room is active or can be created (Roberts, col. 7, lines 26-30). 
Upon making this determination, the Roberts patent simply responds with the name of the chat 
room, and the Roberts patent fails to describe or suggest any other determination or restriction 
before responding to the user request (see at least Roberts, col. 7, lines 15-30). There is no 
suggestion of determining whether the request is received within a threshold period. Once a 
request is received a unique identifier is computed, and the chat client starts a page. 

The Office Action equates "the period of time between initial communication of each 
CD's identifier, and ultimate starting point of the simultaneous playback of an event (the chat 
room)" with the predefined threshold period as recited in at least claim 1 . However, the Roberts 
patent fails to suggest making any determination regarding this period. Instead as described 
above, the only determination made is whether a chat room exists and can be created and the 
Roberts patent fails to describe or suggest that this determination in any way depends on whether 
the chat room has started or the state the chat room is in temporally (see at least Roberts, col. 7, 
lines 15-30). Additionally, Applicants respectfully submit that the Office Action fails to provide 
evidence that demonstrates that the Roberts patent describes or suggest a determination with 
regard to a predefined threshold as recited in claim 1 . 
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Furthermore, Roberts teaches away from making any determination relative to a 
threshold of a start time because a first request immediately activates a chat room and no 
consideration is made relative to a start time, and all subsequent requests are immediately joined 
with the chat room regardless of when the chat is activated (see for example, Roberts, col. 7, 
lines 26-30). The Roberts patent specifically describes that as soon as a determination is made 
that the chat room exists or can be created, the server responds with the name of the chat room. 
Therefore, the Roberts patent does not teach or suggest making any determination of when 
requests are received relative to a start time. 

Similarly, the Craig patent also fails to teach making any determination with regard to 
a predefined threshold as recited in at least claim 1 . According to the Office Action, the 
suggested "initiation" period of the Craig patent is equated with the predefined threshold recited 
in at least claim 1 (see Office Action, pg. 4). However, the Craig patent fails to describe or 
suggest any determination being made with regard to the initiation period before connecting 
students or sending the lecture to the student. Craig describes two types of requests that can be 
received with respect to each lecture. The first is the Instructor server which initiates and 
ultimately starts the lecture. When an Instructor request is first received at the LectureServer, 
the server that is responsible for the coordinating the lecture, establishes a connection with the 
Instructor and "the main thread adds the new Instructors erver to the Hash table which represents 
all lecture sessions maintained by this server" (see at least Craig, col. 14, lines 47-55). The other 
type of request received is a student request. Upon receiving a student request for access to a 
lecture, the Hash table of all lectures is searched to determine if the requested lecture exists, then 
if the lecture exists the system will establish a connection between the student and the Instructor 
for that lecture and "[t]he new student is added to the Vector of currently connected students" 
(see Craig, col. 14, lines 62-67). Craig further describes that "[a]s the actual (human) Instructor 
changes slides, the Instructor applet 71 updates the LectureServer 77, which in turn updates all 
student session" (Craig, col. 10, lines 30-34). When sending these update messages to the 
student the LectureServer of Craig does not teach or suggest making any determination with 
respect to when the student request was received with respect to the "initiation" period. Instead, 
the only determination is whether the student is connected and added to the Vector of all 
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students. This determination cannot be equated to a determination about whether the request 
was received with respect to any threshold period and specifically whether the request was 
received before the starting of the lecture. The Craig patent fails to describe or suggest making 
any determination with respect to when a student lecture is received, instead regardless of when 
a student lecture is received, the LectureServer will only send the update message to those 
students connected (i.e., for which the connection process is completed). Upon receiving an 
update message from the Instructors erver the LectureServer sends the update command to all 
students connected (see at least Craig, col. 10, lines 27-34). According to Craig, if a request is 
received before playback begins but connection has not yet been established, then the student 
sending the request will not receive the first update message with the other students that are 
connected before the lecture begins. Instead, as soon as connection is established the number of 
the current slide being played is sent to the student at that time and not simultaneously with all 
other students whose requests were received before the first update message and for whom 
connection was completed before the first update message (see at least Craig, col. 10, lines 27- 
32, col. 12, lines 19-23 and col. 13, lines 62-67). 

Even if one assumes, arguendo, that Craig describes a threshold period prior to a start 
time, the Craig patent fails to make any determination relative to this threshold period and how 
users are to be connected. Claim 1 not only recites that a determination is made for each user 
relative to the recited threshold period, but also that appropriate action be taken according to 
such a determination. Specifically, claim 1 provides that commands are sent to those client 
apparatuses "for initially beginning the playback of the event at the start time simultaneously 
with the playback of the event on each of the remaining client apparatuses for those requests 
received during the predefined threshold period" and continues to recite that for those requests 
from client apparatuses that are not received during the threshold period that commands are sent 
"for beginning the simultaneous playback of the event simultaneously at a predetermined point 
during the playback." More specifically, Craig describes that regardless of when a student sends 
the request to be connected to the lecture, communication must be established before the student 
can join the lecture. Therefore, even if a student request is received before the instructor starts 
the lecture the student will not receive an update message to start the lecture until and unless 
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connection is established. Thus, the Craig patent fails to teach or suggest making such a 
determination, and further does not teach or suggest sending different commands in response to 
the determination. 

Further, there is no motivation to incorporate any type of determination in that the 
Craig patent is attempting to allow users to access lectures and does not care when students join 
the lecture. The Craig patent describes simply starting the lecture at the time the instructor 
wishes to start. The purpose of the suggested "initiation period" is to "allow students that 
attempt to connect to the presentation some window of time to establish their connection" (see 
Craig, col. 12, lines 7-14). The Craig patent specifically states that the lecture begins when "the 
user at the instructor workstation begins speaking and selecting slides" (see Craig, col. 12, lines 
14-16). Therefore, it is irrelevant when student requests are received, the first update message is 
sent only to those students that have actually established their connection at the time the lecture 
begins and there is no determination of whether the requests were received prior to the starting of 
the lecture. As such, the Craig patent fails to teach or suggest at least "determining whether each 
request is received during a predefined threshold period prior to a start time of initially beginning 
the simultaneous playback of the event" as recited in claim 1, or taking appropriate action in 
response to the determination made. 

Therefore, the combination of Roberts and Craig fails to teach or suggest at least 
"determining whether each request is received during a predefined threshold period prior to a 
start time of initially beginning the simultaneous playback of the event" as recited in claim 1, 
and further fails to teach or suggest taking appropriate action in response to the determination 
made as recited in claim 1 . The combination of applied references fails to teach each limitation 
as recited in claim 1 , and thus, a prima facie case of obviousness has not been established. 

Furthermore, because the chat room is activated at a first request according to 
Roberts, Roberts teaches away from sending commands to a plurality of client apparatuses to 
"initially [begin] the playback of the event at the start time simultaneously with the playback of 
the event on each of the remaining client apparatuses for those requests received during the 
predefined threshold period" as recited in claim 1 . Instead, the Roberts patent only initially 
starts the chat room for a first requesting client device, and all other requesting client devices 
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join during the chat room session. Therefore, the Roberts patent also fails to teach at least the 
"sending [of] the command to the corresponding client apparatus for initially beginning the 
playback of the event at the start time simultaneously with the playback of the event on each of 
the remaining client apparatuses for those requests received during the predefined threshold 
period" as recited in claim 1, and thus, claim 1 is not obvious in view of the Roberts patent. 

Still further, one skilled in the art would not combine the Craig patent with the 
Roberts patent as this would defeat the intended purpose of the Roberts patent. MPEP section 
2143. 01(V) states that "[i]f proposed modification would render the prior art invention being 
modified unsatisfactory for its intended purpose, then there is no suggestion or motivation to 
make the proposed modification." Regarding the Roberts patent, it is the intended purpose of the 
chat room provided by Roberts to allow the users to participate in an interactive experience 
where the users take part in a "complementary entertainment to be meaningfully interactive for 
the consumer, such that the consumer can also be a creator of the experience" (Roberts, col. 1, 
lines 63-65). Alternatively, the Craig patent describes a lecture system where only a single user 
(i.e., the instructor) can control the content. Therefore, one skilled in the art would not combine 
the Craig patent with the Roberts patent as this would restrict the chat room to be controlled by a 
single user (the lecturer) and would thus make it unsatisfactory for and defeat the intended 
purpose of the Roberts patent in providing an interactive experience for the users where the users 
are the creators of the experience. 

Claim 7 and 13 

With regard to claim 7 and 13, as demonstrated above, the combination of the 
Roberts patent and the Craig patent fail to teach at least code and/or logic that evaluate a 
predefined threshold period as recited. Claims 7 and 13 recite language similar to that of claim 1 
at least with respect to "a predefined threshold period prior to a start time of initially beginning 
the simultaneous playback of the event." The Office Action rejects claims 7 and 13 based on the 
same reasoning as presented for claim 1. Applicants respectfully submit that claims 7 and 13 are 
not obvious over the combination of the above references at least for the same reasons as 
described with respect to claim 1 . 
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More specifically the Office Action states that the Roberts patent describes a 
predefined threshold and states, "a predefined threshold period of acquisition can be defined as 
the time during the active participation of said chat room," and alternatively asserts, "the 
predefined threshold period can also be interpreted as the time between initial communication of 
said identifier, and the ultimate starting point of the simultaneous playback of an event (the chat 
room)" (Office Action, pg. 3). However, as described above with respect to claim 1, neither of 
the periods associated with the Roberts patent and suggested by the Office Action can be equated 
with a predefined threshold period prior to a start time of initially beginning the simultaneous 
playback of the event, or code segments and/or logic for determining whether each request is 
received during a predefined threshold as recited in claims 7 and 13. More specifically, the time 
during the active participation of said chat room is not prior to a start time of initially beginning 
the simultaneous playback of the event in Roberts (the chat room). Further, the time between 
initial communication of the CD identifier and the ultimate starting point of the simultaneous 
playback of the chat room cannot be equated with the predefined threshold period, for at least the 
same reasons as described above with respect to claim 1 . 

The Office Action also suggests in reference to the Craig patent that the time between 
the "initiation of a presentation with a slide showing title and presentation start time" can be 
equated with the predefined threshold period. However, at least for the reasons described above 
with regard to claim 1 this period cannot be equated with the predefined threshold period as 
recited in claims 7 and 13, and neither Craig nor Roberts describes code segments and/or logic 
for determining whether each request is received during the predefined threshold as recited in 
claims 7 and 13. Therefore, the combination of the Craig patent and the Roberts patent fails to 
describe or suggest at least a predefined threshold period prior to a start time of initially 
beginning the simultaneous play back of the event or code segments and/or logic for determining 
whether each request is received during the predefined threshold as recited in claims 7 and 13. 

Furthermore, neither the Roberts patent nor the Craig patent describe or suggest code 
segments and/or logic for making a determination based on the predefined threshold period as 
recited in claims 7 and 13 at least for the same reasons as described above with respect to claim 
1 . More specifically, neither of the applied references describes code or logic to make a 
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determination regarding the time at which a request by a client is made before initiating a chat 
session (Roberts) or a lecture session (Craig). Moreover, the Roberts patent teaches away from 
such a determination since the Roberts patent describes starting a chat room upon receipt of a 
first request, and teaches away from queuing users before starting a chat session, and instead 
describes that upon receiving a chat request a chat client is created on the user device. As such 
the combination of the Craig and Roberts patent fails to teach all of the limitations at least with 
respect to claims 7 and 13, and therefore, the above combination fails to render at least claims 7 
and 13 obvious. 
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(8) Claims Appendix 

Provided is a complete listing of all the pending claims involved with this appeal: 
Claim 1 : A method for identifying playback devices of a plurality of client apparatuses 
which are networked to simultaneously playback an event, comprising the steps of: 

receiving requests from each of the client apparatuses to simultaneously playback the 

event; 

identifying a type of the playback device of each of the client apparatuses; 

looking up a command associated with the identified type of the playback device; 

determining whether each request is received during a predefined threshold period prior 
to a start time of initially beginning the simultaneous playback of the event; and 

sending the command to the corresponding client apparatus for initially beginning the 
playback of the event at the start time simultaneously with the playback of the event on each of 
the remaining client apparatuses for those requests received during the predefined threshold 
period, and sending the command to the corresponding client apparatus for beginning the 
simultaneous playback of the event simultaneously at a predetermined point during the playback 
for those requests not received during the threshold period. 

Claim 2: A method as recited in claim 1, wherein the event includes a video and audio 
presentation. 

Claim 3 : A method as recited in claim 1 , wherein the type of the playback device is 
identified utilizing the network. 

Claim 4: A method as recited in claim 1, wherein the network is a wide area network. 

Claim 5 : A method as recited in claim 1 , and further comprising the step of storing on 
the client apparatus an identifier of a host server that sent the command. 
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Claim 6: A method as recited in claim 1 further comprising playing a digital video disc 
(DVD) during the event. 

Claim 7: A computer program embodied on a computer readable medium for identifying 
playback devices of a plurality of client apparatuses which are networked to simultaneously 
playback an event, comprising: 

a code segment for receiving requests from each of the client apparatuses to simultaneous 
playback the event; 

a code segment for identifying a type of the playback device of each of the client 
apparatuses; 

a code segment for looking up a command associated with the identified type of the 
playback device; 

a code segment for determining whether each request is received during a predefined 
threshold period prior to a start time of initially beginning the simultaneous playback of the 
event; and 

a code segment for sending the command to the corresponding client apparatus for 
initially beginning the playback of the event at the start time simultaneously with the playback of 
the event on each of the remaining client apparatuses for those requests received during the 
predefined threshold period, and sending the command to the corresponding client apparatus for 
beginning the simultaneous playback of the event simultaneously at a predetermined point 
during the playback for those requests not received during the threshold period. 

Claim 8: A computer program as recited in claim 7, wherein the event includes a video 
and audio presentation. 

Claim 9: A computer program as recited in claim 7, wherein the type of the playback 
device is identified utilizing the network. 
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Claim 10: A computer program as recited in claim 7, wherein the network is a wide area 
network. 

Claim 1 1 : A computer program as recited in claim 7, and further comprising a code 
segment for storing on the client apparatus an identifier of a host server that sent the command. 

Claim 12: A computer program as recited in claim 7 further comprising a code segment 
for playing a digital video disc (DVD) during the event. 

Claim 13: A system for identifying playback devices of a plurality of client apparatuses 
which are networked to simultaneously playback an event, comprising: 

logic for receiving requests from each of the client apparatuses to simultaneous playback 
the event; 

logic for identifying a type of the playback device of each of the client apparatuses; 
logic for looking up a command associated with the identified type of the playback 

device; 

logic for determining whether each request is received during a predefined threshold 
period prior to a start time of initially beginning the simultaneous playback of the event; and 

logic for sending the command to the corresponding client apparatus for initially 
beginning the playback of the event at the start time simultaneously with the playback of the 
event on each of the remaining client apparatuses for those requests received during the 
predefined threshold period, and sending the command to the corresponding client apparatus for 
beginning the simultaneous playback of the event simultaneously at a predetermined point 
during the playback for those requests not received during the threshold period. 

Claim 14: A system as recited in claim 13, wherein the event includes a video and audio 
presentation. 
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Claim 15: A system as recited in claim 13, wherein the type of the playback device is 
identified utilizing the network. 

Claim 16: A system as recited in claim 13, wherein the network is a wide area network. 

Claim 17: A system as recited in claim 13, and further comprising logic for storing on 
the client apparatus an identifier of a host server that sent the command. 

Claim 18: A system as recited in claim 13 further comprising logic for playing a digital 
video disc (DVD) during the event. 
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(9) Evidence Appendix 

None 
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(10) Related Proceedings Appendix 

None 
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CONCLUSION 

Appellants submit that the rejections of the pending claims 1-18 are in err, and that 
claims 1-18 are patentable over the applied combinations of references. 

Appellants respectfully request a reversal of the final rejection. 
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